This crash happens more often when the test case is dragged and dropped, but it is not required. The browser was launched with GNOME_ACCESSIBILITY=1 set ==56678==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000001c (pc 0x7f56f68bf6a2 bp 0x7ffc01b57a50 sp 0x7ffc01b57a20 T0) ==56678==The signal is caused by a READ memory access. ==56678==Hint: address points to the zero page. #0 0x7f56f68bf6a1 in GetBoolFlag src/dom/base/nsINode.h:1600:12 #1 0x7f56f68bf6a1 in IsInUncomposedDoc src/dom/base/nsINode.h:538 #2 0x7f56f68bf6a1 in GetPrimaryFrame src/obj-firefox/dist/include/nsIContent.h:909 #3 0x7f56f68bf6a1 in GetPrimaryFrame src/obj-firefox/dist/include/mozilla/dom/Element.h:1194 #4 0x7f56f68bf6a1 in mozilla::a11y::SelectionManager::SetControlSelectionListener(mozilla::dom::Element*) src/accessible/base/SelectionManager.cpp:76 #5 0x7f56f695fb13 in mozilla::a11y::DocAccessible::CreateSubtree(mozilla::a11y::Accessible*) src/accessible/generic/DocAccessible-inl.h:181:7 #6 0x7f56f695f580 in mozilla::a11y::DocAccessible::ProcessContentInserted(mozilla::a11y::Accessible*, nsTArray<nsCOMPtr<nsIContent> > const*) src/accessible/generic/DocAccessible.cpp:1909:7 #7 0x7f56f68cca37 in mozilla::a11y::NotificationController::WillRefresh(mozilla::TimeStamp) src/accessible/base/NotificationController.cpp:727:16 #8 0x7f56f36f8057 in nsRefreshDriver::Tick(long, mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:1854:12 #9 0x7f56f37077d5 in mozilla::RefreshDriverTimer::TickRefreshDrivers(long, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) src/layout/base/nsRefreshDriver.cpp:298:7 #10 0x7f56f3707492 in mozilla::RefreshDriverTimer::Tick(long, mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:319:5 #11 0x7f56f3709b2b in RunRefreshDrivers src/layout/base/nsRefreshDriver.cpp:761:5 #12 0x7f56f3709b2b in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:674 #13 0x7f56f3704e97 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::ParentProcessVsyncNotifier::Run() src/layout/base/nsRefreshDriver.cpp:520:20 #14 0x7f56ec9e8a1e in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1446:14 #15 0x7f56ec9eec98 in NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:480:10 #16 0x7f56ed800951 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:97:21 #17 0x7f56ed75de1b in RunInternal src/ipc/chromium/src/base/message_loop.cc:326:10 #18 0x7f56ed75de1b in RunHandler src/ipc/chromium/src/base/message_loop.cc:319 #19 0x7f56ed75de1b in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:299 #20 0x7f56f3014e4f in nsBaseAppShell::Run() src/widget/nsBaseAppShell.cpp:156:27 #21 0x7f56f70f45f1 in nsAppStartup::Run() src/toolkit/components/startup/nsAppStartup.cpp:287:30 #22 0x7f56f72d02d4 in XREMain::XRE_mainRun() src/toolkit/xre/nsAppRunner.cpp:4596:22 #23 0x7f56f72d1ed8 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) src/toolkit/xre/nsAppRunner.cpp:4760:8 #24 0x7f56f72d330b in XRE_main(int, char**, mozilla::BootstrapConfig const&) src/toolkit/xre/nsAppRunner.cpp:4855:21 #25 0x4eb643 in do_main src/browser/app/nsBrowserApp.cpp:236:22 #26 0x4eb643 in main src/browser/app/nsBrowserApp.cpp:309 #27 0x7f5709faa82f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291 #28 0x41d198 in _start (m-c-1501248297-asan-opt/firefox+0x41d198)

interesting, according to the stack trace, it looks that focusedAcc->GetNode() is null, curious to know what is focusedAcc then

I just started working on this one, I'll let you know! From my local reproducing, it happens when the entire window is blurred.

The focusedAcc is the BR accessible, and it doesn't have associated content (hence the null Element being passed to SelectionManager).

(In reply to Eitan Isaacson [:eeejay] from comment #3) > The focusedAcc is the BR accessible, and it doesn't have associated content and that's where the wild things are :) since we are in the middle of tree creation, we have to have a good accessible with node and all stuff. Is this node is in good state like no eIsInDocument/Defunct states? I'm curious if it didn't pop up from previous tree destructions somehow.

This took me on a lot of windy paths. Bottom line: This is happening because a shutdown accessible is left in mAriaOwnsHash. This is due to bug 1385372 allowing duplicate accessible's in the hash's arrays, and only the first instance of the accessible is deleted.

Verified that I can't reproduce this with the fix in bug 1385372.

Tyson, can you verify that this issue is fixed in the next nightly?

(In reply to Eitan Isaacson [:eeejay] from comment #7) > Tyson, can you verify that this issue is fixed in the next nightly? I can no longer reproduce this issue on the latest nightly. BuildID=20170810152033 SourceStamp=5322c03f4c8587fe526172d3f87160031faa6d75

This bug was fixed by the fix in bug 1385372.